Subject: APPN ISR over ATM

From: "J. G. Dudley (444/4358)" <[email-masked]>
Date: Mon, 16 Oct 95 15:30:43 EDT

Ref:  Berl note of 9/27/95
      Cobban note of 10/13/95

I concur with the opinions expressed by Jim Cobban.  To achieve
significant customer value, ISR over native ATM requires architectural
definition beyond the encapsulation formats.  In addition, ISR has
limitations in the high speed WAN arena.  As a result, ISR over native
ATM provides only limited additional value above that provided by LAN
emulation and frame relay emulation, which can be used for ISR over ATM
with no new APPN architecture.

I believe ISR over native APPN will slow down the HPR over native ATM
effort and introduce interoperability and migration issues.  In a
mixed environment, additional overhead (either in the form of negotiation
or coordinated configuration) is required beyond that required for an
HPR-only solution.  Therefore, I recommend that the AIW not spend any
resources on ISR over ATM.

Gary Dudley
IBM APPN Architecture Team

---

From: Dario Calia <[email-masked]>
Date: Mon, 16 Oct 95 18:25:47 PDT

Hello Jim,

Thanks for the broad expansion of the very simple question. I would
love to discuss the points and topics you brought into this thread,
but I would like everyone to focus on the single issue Steve
presented.  

The current wording in the document leads one to believe that no
vendor could implement APPN ISR over ATM using the encapsulation
technique submitted by IBM.  I feel there are many reasons for
transporting APPN ISR over ATM using this simple technique.

First and foremost, customer requirements.  Some customers would like
to encapsulate APPN traffic over ATM today.  They do not require the
more advanced features being architected.

Second, as Jim pointed out, it's simple.  Similarly, in the globe of
the specification, this is a trivial issue and should be taken as a
simple editorial change.  It's amusing to see so much discussion.  Add
the simplicity to the customer demand and you have a formula for
success.

Third, ease of migration.  You've got instant access to an ATM network
and you don't care who's at the other end.  You can then gradually
migrate pieces of your network to take advantage of the more advanced
features as you need them.

Fourth, flexibility.  This is both for vendors and customers.  You
can choose to use HPR over ATM or ISR over ATM.

Okay, the request is simple.  Let's change the wording to accomodate
the APPN ISR enapsulation technique submitted by IBM as a native ATM
DLC and state that this version of the architecture will not
specifically attempt to solve the QOS/COS mapping issues, the CN
issues, etc. for ISR.

Ciao, Dario

Forwarded message:
> From [email-masked] Fri Oct 13 16:00:44 1995
> Date: Fri, 13 Oct 1995 19:00:39 -0400
> Message-Id:  <"21690.Fri.Oct.13.18:55:24.1995"@bnr.ca>.
> X-Deleted-Errors-To: [email-masked]
> Reply-To: [email-masked]
> Originator: [email-masked]
> Sender: [email-masked]
> Precedence: bulk
> From: "jim (j.) cobban" <[email-masked]>
> To: [email-masked]
> Subject: re:"Steven H. Berl": APPN ISR over ATM 
> X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
> X-Comment:  High Performance Routing (HPR)
> 
> In message ""Steven H. Berl": APPN ISR over ATM", you write:
> 
> >In the ATM-01 document section 1.2.3 entitled "Native ATM DLC", in the
> >secod to last paragraph, it is stated that:
> >
> >      "Because HPR is a prerequisite for the native ATM architecture
> >      described in Chapter 2, "Native ATM DLC", the native ATM architecture
> >      does not support APPN/ISR FID2 traffic. Likewise, it cannot be used
> >      for links between DLUR nodes and down-stream nodes with dependant LUs.
> >      Additional architectural definition is required for such
> >      configurations. For example, an LLC such as IEEE 802.2 type 2
> >      providing error recovery must be specified."
> >
> >In the ATM Forum Technical Committee, a contribution has been
> >submitted by IBM entitled "Multiprotocol over ATM Adaptation Layer
> >Type 5 Implementation Agreement". This is ATM Forum/94-0615. This
> >document describes the encapsulation of 802.2 type 2 traffic for
> >APPN/ISR FID2 traffic, as well as several other types of SNA traffic.
> >
> >This sounds like the "additional architectural definition" refered to
> 
> The encapsulation format for the frames is the easiest, and therefore the
> least important, aspect of supporting ISR traffic over ATM.  Of the 50 pages
> in the IBM proposal presented at the last AIW only ONE addressed
> encapsulation techniques, and it just says "See RFC 1483".
> 
> The much larger considerations addressed in this proposal are how to choose
> a route through an ATM network, how to map APPN COS to ATM COS, how to
> implement Connection Networks to select single hop paths through an ATM
> network, and where we, the AIW, would like to see the ATM vendors deliver
> functionality.
> 
> There is clearly nothing to prevent anyone from implementing an ATM data
> link layer for ISR.  Since the RFC1483 and RFC1490 encapsulations are
> aligned, for most implementations it will simply be inserting a mapping from
> the Q.922 frame to the AAL5 format for ATM.  However it must be remembered
> that our Frame-Relay implementations are only for PVCs.  Even if we extend
> those implementations to support SVCs in a trivial way, we will not be
> gaining the advantage of, for example, connection networks, for which there
> is no architectural agreement.
> 
> The question before the AIW is therefore whether we wish to dilute our focus
> by addressing the extension of COS mapping and Connection Networks into ATM
> in both the ISR and HPR environments.
> 
> As a major vendor of equipment for public data networks for 2 decades Nortel
> would LIKE to see Connection Networks supported in X.25 and Frame-Relay as
> well as ATM.  As is well known in our community I have been trying to push
> that for many years.  However can we AFFORD the dilution of effort?  I am 
> afraid not.
> 
> As one technical issue:  LLC2 is designed for a medium with highly reliable
> delivery and minimal end-to-end delay, that is LANs, particularly Token-Ring
> LANs.  It has fixed transmission windows and fixed recovery timers.  It is
> therefore not well suited to being transported over a WAN with potentially
> large delays, comparatively poor reliability, and significant variation in
> delay and throughput capacity.  Furthermore the smallest unit of
> retransmission is a whole frame.  HPR has adaptive transmission windows and
> variable recovery timers.  It is capable of retransmitting any set of bytes,
> for example it could retransmit the contents of an individual ATM Cell if
> necessary.  It is therefore ideally suited to be used over an ATM WAN.
> 
> Jim Cobban   |  [email-masked]                        |  Phone: (613) 763-8013
> BNR Ltd.     |  bnrgate.bnr.ca!bcars153!jcobban       |  FAX:   (613) 763-5199
> |                                                                             |
> |   The opinions expressed are those of the author and do not necessarily     |
> |   represent the opinions of Bell-Northern Research or Northern Telecom.     |
>